開発生産性Conference参加レポート #開発生産性con_findy

はじめに

しばらく夏休みを頂いており、月を跨いでしまいましたが、2023年7月13日に開催されたFindy様の開発生産性Conferenceの参加したセッションの感想をまとめようと思います。

他のセッションに関しては、こちらをご覧ください。

参加セッションと感想

セッション内容を自分なりにまとめつつ、感想を交えレポートを記載しています。自分の解釈が誤っている箇所があれば @shuntaka_jp までご連絡ください。

なぜ Four Keys を改善するのか？ 〜How ではなく Why を重視したメトリクス改善活動〜

登壇者
株式会社リンクアンドモチベーション 川津 雄介様

感想

現在私は、横断的に開発チームの生産性向上に取り組む部署にいるため、参考になる点が多かったです。Four Keysをなぜ改善するのか？なぜを明確にしないと指標に権威があっても開発チームは動き辛いし、結果的に生産性が下がることがあるケースを学ぶことができました。

本セッションはスライドがあるので、そちらを見るのが良いと思いますが、自分なりに参考になった点を以下にまとめます。

Four KeysのWhy

Four KeysのTierを目標に、チームでデプロイ頻度を改善したが、リリース作業時間が多く、リリース担当者が開発できず実際に生産性が下がっているケースがあった。チームでデプロイ頻度をあげたい理由を考えた際に、様々機能を含んだリリースを実施した際に途中でマイグレーション(Rails利用の場合)が挟まると切り戻しの工数やMTTRの悪化に繋がっている課題があった。機能とリリースが紐づいているのが理想だと考え、結果切り戻しや再リリースの工数削減やMTTRの向上ために、デプロイ頻度をあげるというWhyを明確にした。

またリードタイムの改善については、「機能を作ってお客さんに届けるまで」という解釈をすることがあるが、Four Keys上のリードタイムは「First commitしてからmasterマージして本番にデプロイされるまで」であり、ビジネス上のリードタイムとは異なる。つまりPR・Featureをリリースするのにかかった日数となる。 PRが小さいと品質はあがる。なぜならPRが大きいと全てファイルはどうしても見切れないし、設計的な観点だけになりがちになる。影響範囲も大きくテスト範囲も大きくなる。PRを細かくするのが大変という見方もあるが以下の観点でメリットが大きかった。

• 1行単位でレビューできる
• テスト範囲が明確(テスト工数がへる)
• リリース調整が必要なくなる

リードタイムを短くすることで、障害を減らし、リリースの複雑度を減らしたいというWhyを明確した。

本組織では、デプロイ頻度を上げたらMTTRが下がり、リードタイム短縮したら変更障害率が下がったことから、メトリクスは切り口が異なるだけで影響しあう部分もある。大切なことは、低いメトリクスの数値に振り回されず、その数値が何に起因しているのか、どういう意味なのか、どのような課題があり、どこを目指したいかを明らかにすること。

チームの壁を超えて一丸となって開発する

本組織はSREが改善活動を推進しており、アプリ開発チームは基本的に忙しく、生産性改善活動は行いたいくてもミッションではなかった。なので各アプリ開発チームで興味がある人を組織横断型のチームに選出した。また活動をボランティアにするのではなく、個人目標と紐付けるようにした。

各チームがMTTRが高い状態にあった際に、組織横断チームがヒアリングしたが原因が分からない時があった。その際には一定期間アプリ開発組織に異動し(埋め込み)、直接改善を行う前述とは逆のパターンも紹介があった。

中集権的に開発チームに対して改善活動をお願いしているが、これは理想ではなく、組織が拡大した際にスケールが難しい。チームの誰かがロールをもつというやり方もあるが、全員ができる方が良い。 故に、生産性改善のオーナーシップを「チーム」にし、組織横断型チームのメンバーが改善活動を並走し、やり方をレクチャーするようにした。内容としては、「メトリクスの計測」や「改善運用/プロセスの設計(目標に組み込めると理想的)」や「なぜそれをするのか」を各チームにレクチャーするようにしている。

Four Keys改善だけはない。ZOZOTOWN/WEARの開発生産性向上の取り組み

登壇者
株式会社ZOZO 御立田 悠様 / 堀江 亮介様
Findy Team+ 内田 博咲也様

感想

株式会社ZOZOのWEARとZOZOTOWNの開発生産性向上の取り組みについてのセッションでした。

ZOZOTOWNの事例では、生産性可視化の取り組み始めというフェーズでした。課題定義から始まり、そもそも生産性レベル1,2,3のうちどれを見るかや基盤、開発フローの整理などこれから可視化を始めたいと思ってる自分の組織からすると動き出し参考になる点が多かったです。

WEARの事例では、Four Keysをそのまま使うのではなく、組織横断的に測りやすく効果が高い指標を定めて改善し、劇的な改善をしていた。他のセッションでもありましたが、レビュワーに優しいプルリク作りは、生産性に大きく寄与する事例が多いなと感じました。

自分なりに参考になった点を以下にまとめます。

ZOZOTOWN(堀江さん)

会社としてやりたい施作が多く、開発案件が渋滞していた。当時のCTOとプロジェクトを作り、開発生産性を向上してユーザーの提供価値を増やす取り組みを行うこととなった。 ユーザーの提供価値増やすために、質と量をどうするかを考え、初めは量からやっていくこととした。量を増やすために、リードタイムに着目し、施作が沢山できる組織になるにはどうしたら良いかを考えるようにした。

ZOZOTOWNでは、現在レベル1とレベル2の生産性可視化を進めている。レベル1の生産性の可視化に関してはFindy Team+を導入し取り組んでいる。ZOZOTOWN自体はまだ明確に成果出ておらず、道半ば。何を可視化したいのか、開発プロセスの整理して計測できるような仕組み作りをしている。

なかなかFindy Team+をうまく使ってもらえない問題があった。社内説明会をしても十分に活用してもらえなかったため、個別やチーム毎にFindyさんと一緒にフォローするようにした。可視化基盤や説明会をするだけでは足りず、チームや個別にフォローする必要があった。

WEAR(御立田さん)

開発生産性3倍という目標をたて、具体的に落としていく過程でプルリククローズ時間を24時間以内にしようと掲げたとのこと。本カンファレンスのDr.Nicoleの話でもあったようにSPACEフレームワークのアクティビティは計測しやすい。

Four Keysという指標がある中でなぜ前述のような指標にしたか?デプロイ頻度だと横軸で測るのには組織的な制約があり(セールスやカスタマサポートの連携など)、開発組織としてコントロール可能な指標でなかったため。

プルリククローズ時間24時間以内にするために行った施作としては、まず現状把握を元々導入されていたFindy Team+を活用した。現状把握時は遅く、なぜ遅いかを考えたところレビューに起因する結論に至った。プルリクをクローズを早くするために行き着くところは「レビューワーに優しいプルリク」だった。

そもそも開発内容に不備がないか？品質問題ないか？をチェックするためプルリクなのに、レビュワーに変更行数が多いプルリクを渡すと確認が大変。案件管理ツールとしてJIRAを使っており、サブタスク機能をつかって親タスクに対して細かい粒度で子タスクを定義しその単位でPRを出すようにした。1個のPRの目的が明確になるようにした。QAであった内容だが、PRを細かくすると全体観がわかりにくくなるという問題に関しては、プルリクテンプレートを利用し親タスクのリンクをつけるようにしているとのこと。WEARは、21年10月から11月末まで240時間(10日)だったPRクローズ時間が、22年4月-8月末までは30時間となり、この数値は実感を伴っているとのことだった。

QAで参考になった箇所

Q.各チームに価値を説明し、その時は利用してくれなくても、時間が経つに連れて形骸化したりしないのか。一時的なものではなく、継続的に生産性を可視化したり、向上できるようにするためにやったことはあるのか

A. (堀江さん) 定期的にみてもらうことが大事。1on1の振り返りに使ってもらう。継続的に使い、習慣化しやすくなる (御立田さん) 数値として結果が出て、なんで続くかというとレビュワーに優しいPRを作ることで自分達が楽になっていく。これは多くの場合開発者が実装とレビュー両方をやることが多いため。楽になることで続いていく。配慮が自分にも跳ね返ってくる。

Q. ペアプロ、モブプロで開発した場合、レビューも兼ねることができて、レビューまでのクローズ時間が短くなると思うが、ペアプロ・モブプロについてはどうおもいますか？

A. (堀江さん) ペアプロ、モブプロについては、各チームで改善を回すという形。 (御立田さん) どんどんやるべきだが、強制をするものではないと思っている。各自必要に応じてやる。実際ペアプロしたコードはマージまでが早い。

Four keysを超えて 〜信頼性はいかに開発生産性を高めるのか〜

登壇者
グーグル合同会社　山口 能迪様

感想

2018年State of DevOpsレポート以降Four Keysに加えて信頼性が追加されている。ユーザーの信頼性を数値化するために近似値としてSLIを計測し、SLOを定義する。SLOを満たしていれば、ユーザーは満足しているとみなしているため、残りをエラーバジェットとして管理し、バジェットを例えば信頼性の向上であったり、Four Keysの改善に使えるという内容でした。

私はFour Keysも最近LearnとDevOpsの科学で知ったので、本セッションで5つ目の指標の存在が知りました。2022年のState of DevOpsレポートは、日本語訳版もあるので読んでみると気づきがあると思います。また、エラーバジェットは、開発者が現在開発運用しているシステムで行いたい非機能要件などをなぜ今やる必要があるのか客観視する指標として、とても有効だと感じました。以降セッションであった内容を自分なりにまとめます。

5番目の指標「信頼性」

「LearnとDevOpsの科学」は、2014年-2017年のState of DevOpsのまとめである「ACCELERATE」が原著。そのため2018年以降のState of DevOpsのレポート内容が反映されていません。2018年のState of DevOpsレポートで追加された「可用性」指標、それが2022年のState of DevOpsで発展し「信頼性」指標として定義されたとのことでした。 開発 - デプロイフェーズでは、「デプロイ頻度」「変更のリードタイム」指標、運用は「信頼性」指標、障害-復旧フェーズでは「変更障害率」「サービス復旧時間」指標を活用すると整理するとわかりやすいです。

信頼性

信頼性(Reliability)とは、「(システムが)求められた機能を、定められた条件の下で、定められた期間に渡り、障害を起こすことなく実行する確率」のこと。

信頼性指標の測定方法

信頼性を計測するためには、ユーザーがおそらく満足して使ってくれるだろうと分かる信頼性指標の元データを探す必要がある。モニタリングシステムの指標が使える場合もあるが、ユーザーからみた際に本当に信頼性指標の元データとして適切かは確認する必要があるとのことだった。

サービスレベル指標(SLI)

信頼性指標の元データが用意できた場合、サービスレベル指標(SLI)が定義できる。定義は以下の通り。

(良いイベント/有効なイベント) x 100%

可用性のサービスレベル目標を定義する場合、例えば良いイベントにHTTP(2xx, 3xx, 4xx)のレスポンス、有効なイベントに全レスポンスが当てはまる。

サービスレベル目標の定義(SLO)

前述のSLIを元にサービスレベル目標(SLO)を決めます。良いイベントの割合を決めるため、継続期間(過去28日間など)で目標値がどれくらいか、良いイベントがどれくらいの割合であるべきかを定義する。

エラーバジェット

SLOを満たせば、ユーザーは満足することから、許容可能な不具合の量を決定する事が出来る。これをエラーバジェットと呼ぶ。仮にSLOを99.9%ととした場合、30日間の1%である43.2分をバジェットとして扱う。このバジェットを管理し、ダウンタイムをユーザー許容範囲内に収めつつ、取り組む内容の指針とする。 エラーバジェットが十分にある場合は、開発のベロシティを優先する。エラーバジェットを消費してしまった場合、信頼性を優先した取り組みを行うなど。またシステムのエラーバジェットを管理することで、設定したSLOを満たすことが可能なシステム構成なのか、振り返る客観的な指標となる。

バーンレート

エラーバジェットが消費される速度。例えばSLO 30日99.9%の場合、0.1%が30日で消費される。0.1%が14日で枯渇する場合、バーンレートが2となる。この消費される速度を確認し、取り組む内容の指針とするのが良い。

Four Keys改善のハードシングス！NewsPicks・バイセル・はてなが直面したハードルと乗り越え方

登壇者
株式会社ユーザベース 高山 温様
株式会社BuySell Technologies 渡邊 直人様
株式会社はてな 大仲 能史様
Findy Team+ 内田 博咲也様

感想

3社ともFindy Team+を実際に導入されている事例で、参考になる点が多かったです。指標の定義を精緻にするより、まず計測し始めてみる姿勢が大事だなと思いました。統一的な図り方で比較し、その上で色んなチームの個別事情を加味すればよいためです。他にもPRの粒度や開発組織自体が生産性改善活動に自走していく過程の話など、目指すべきゴール指針が見える良いセッションでした。

生産可視化指標何を見るか

• はてな(大仲さん)
  • Four Keysをみており特にみているのはデプロイ頻度。
  • デプロイ頻度が一番取りやすい、他の指標は頑張らないといけない点がある。
• BuySell(渡邊さん)
  • リードタイム、サイクルタイム、PR数
• ユーザーベース(高山さん)
  • デプロイ頻度をかなり重視している。最初からデプロイ頻度にフォーカスして改善した際にとてもうまく行った経験がある
  • (渡邊さん) ユーザーベース高山さんの記事をみて、デプロイ数だけで効果が高いという気づきがあった。会社で推進する際に背中を押してもらった。
  • (大仲さん) デプロイ頻度が一番取りやすい、他の指標は頑張らないといけない点がある。

どの程度正確に計測しているか

指標として使うのに、デプロイ頻度の定義を全チームで揃えるのか？や変更のリードタイムを最初どこにして、最後どこにするか？をどの程度正確に計測しているか。

• はてな(大仲さん)
  • 定義が色々あるのは知っていた。定義の議論は曖昧のまま、チーム毎に比較できることように、指標を計測することから始めた
  • 弱いチームは明確に値が違うはずで、定義を細かく揃えるより、凹んでいるチームを探す方がアクションに繋がりやすいと考えた
• BuySell(渡邊さん)
  • Findy Team+のデフォルトで計測した。正確にやろうとすればするほどチーム毎にバラけたり、コストが高くなる。
• ユーザーベース(高山さん)
  • LearnとDevOpsの科学によると、Four Keysがあるがエリートなチームは全ての指標が高いとされている。またCircleCIのレポートだとmainブランチのビルド失敗時間をとるなど、有用な指標はいくつかあり全ては相関している。
  • デプロイ頻度が週一で決まっているケースなどがあり、mainブランチへのマージの数をデプロイ頻度として比較するようにしている

1日のPR数について

• はてな(大仲さん)
  • 1人1個PRを出しているか気にしている。PRの大きさの粒度が揃ってくる。ストーリーポイントがいくつだったらどれくらいで終わるか認識が揃ってくる。
• BuySell(渡邊さん)
  • 1チームで1人あたり1日3PR出すことを掲げた。3PR出すようにチケットやタスク分解をするようになった。結果として開発者体験が上がった。3PRが正義かは分からないが、一旦チームとして置いてみてやってみて良い結果が得られた。

指標をみながら改善活動をするために感じたハードル

• はてな(大仲さん)
  • スクラムマスターが集まるサブ会で数値を見比べて、チームに持ち帰り話すようになった。
  • リードタイムが悪いチームに持ち帰って話してみたところ、リードタイムあげたら何が良くなるのか？質問があった。その時明確な答えが出せなかった。推進する人はなぜやるのかを明確にしないといけない。
  • チームの事情に合わせて、目指すゴールを推進する人が定義し直す必要がある。個別の事情を理解しつつ、進めて行かない。
  • チームが元々持っている課題と沿っていることも重要。Four Keysの指標はゴールで、その前段にある課題に対してアプローチする必要がある。
• BuySell(渡邊さん)
  • 自分はチームのマネージャーではないため、改善から入れない。まず明確なハードルがあり、チームが乗り越えたいと感じている場合に並走する
  • 改善ができているかどうかの判断が難しい。指標を解釈する力が必要。そこをミーティングの中で、フォローするようにしている。
  • 開発チームが成功体験を得るまで伴走することを大切にしている
• ユーザーベース(高山さん)
  • 改善活動を始めたとき、世の中的には流行っていなかったため、大変だった
  • SREと一緒に進め、デプロイ頻度を上げるために、デプロイエンジニアリングを1年半くらいやったが、デプロイ数がなかなか2年上がらなかった。ただ開発者体験、開発者生産性が大事と言い続けた結果、各チーム達が自発的に指標を見るようになり、改善活動をして良くなっていった。

PRのレビューに関して

• はてな(大仲さん)
  • レビューが来たらすぐレビューするか、今の自分の仕事をやっているから放置する人もいる。中には5分以内にレビューを返すことを心がけている人にとっては、24時間放置されたら遅いと感じる。平均したらそこそこになる。遅い人に対してヘイトが溜まると良く無いので、早い人にやり方を教わる。Findy Team+をみて人毎のレビュー時間のムラを見て、振り返りでこういう話題を出してとお願いする。
• BuySell(渡邊さん)
  • 誰のレビュー時間がどれくらいかがFindy Team+で見れる。遅い人がどうやったら早くなるかをチームの課題として取り組む。仕事の進め方、レビューがきたらすぐレビューするのか？自分の自分タスクを優先したらうまく回らないのでは？など議論する必要がある。エンジニア自身が仕事の進め方を変えるきっかけになる。
• ユーザーベース(高山さん)
  • PRを作ったらZapierがレビューの期限をGoogleカレンダーに登録するなど、チームごとに改善活動をしている

レビュー時間が遅い人を掘り下げると、PRがすごい巨大であることが原因のケースもあり、チームの問題であるケースがある。

ゴールをどこに置いているか

生産性可視化のゴール

• はてな(大仲さん)
  • State of DevOpsのTier(2022ではなくなったが)で、3年後にはEliteを目指すことを目標にしていた。自分の会社を世の中でイケている状態にしていたい。先頭集団にいることを目標にしている。
• BuySell(渡邊さん)
  • Four KeysがEliteであること。ただチームの個別事情を加味してサポートするようにしている。
• ユーザーベース(高山さん)
  • 開発生産性を可視化することで課題のレベル感が変わった。開発メンバー一人一人が数値を見ることで、数値を使った目標の定義や課題感の認識、そこからより具体的な施作の提案、改善活動ができるようになった。この活動を広げていきたい。定量的な数値があることから、説得や交渉コストが減った。
  • (渡邊さん) 横串の改善活動を通じて、嬉しい経験として、チームメンバーがリーダシップを発揮する場面が増えた。例えばPRの大きさを60行以下してみるといったアグレシッブなチャレンジが増えた。可視化を通じて、チームメンバーがより提案しやすく環境になった。
  • (大仲さん) 目標を明確におくことでアクション変わる。数値でおくことは大事。また人にジョブタイトルをつけて、活動内容が明確し、動きやすくなった。

QAで参考になった箇所

Q. コストがかかる可視化ツール(Findy Team+など)導入をどう説得するか
A. (大仲さん) 1on1の前にマネジャーがチームのPRが出ているのか、レビューが回っていのかをデータを揃えていた時間を短縮する。1on1をやるマネジャーのもう1つ上のマネジャーが概要を把握しやすくなる。1人マネジャーを減らすことも出来ると考えるとコスト効果がある。

Q. PRレビュー着手を早くする目標を立てた場合、自分実装にはまった際に、タスク着手ができずストレスがたまらないか？そもそも目標を立てているのかや立てていた場合、このような問題をどうケアしているか
A. (渡邊さん)自分の実装がはまる状態が課題。設計や仕様に問題がないか振り返る。 (高山さん)数値目標は、個人のパフォーマンスを測るために使わない。プルリクからアプルーブまで時間はチームとしての努力目標として、チームとしてどう改善できるかを考える。 (大仲さん)努力目標とする。個人のパフォーマンスを測るために使わない。振り返りの際にFUNがあったか、コード書く時間がちゃんとあったかを振り返り、状況に応じてレビューを他に人に回すなど調整をする。

最後に

開発生産性は非常に様々な要素が絡み合う領域であることをイベントを通して再認識しました。また横断的に開発生産性を向上しようと取り組んでいる組織が多く、私自身担当者の端くれととして共感できる点が多かったです。

今回参加したKABUONEですが、イベントスペースは、非常に綺麗な会場で新鮮でした。このような機会を提供してくださったFindy様スピーカーの皆様ありがとうございました！